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Abstract 
This paper documents some of the usage patterns and the associated 
issues when deploying a Home Network for Network Mobility (NEMO) - 
enabled Mobile Routers, conforming to the NEMO Basic Support. The 
aim here is specifically to provide some examples of organization of 


the Home Network, as they were discussed in NEMO-related mailing 
lists. 
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Introduction 


This document assumes that the reader is familiar with IPv6 Mobility 
as defined by Mobile IPv6 and the Network Mobility (NEMO) Basic 
Support. In order to read this document properly, it is important to 
realize that in NEMO, the Home Network can encompass much more than 
the Home Link, as it spans the Home Link and all the Links that the 
Mobile Routers (MRs) carry with them. Exactly how the two concepts 
relate in a given deployment depends on the organization of the Home 
Network, as described below. 


Five different organizations of the Home Network including a 
hierarchical construction are documented: 


MIPv6 Home Network: A short reminder of what the Home Network is 
with Mobile IP, in order to help the reader figure out the 
evolution toward NEMO. 


NEMO Extended Home Network: In this arrangement, the Home Network is 
only one subnet of a larger aggregation that encompasses the 
Mobile Networks, called Extended Home Network. When at home, a 
Mobile Router performs normal routing between the Home Link and 
the Mobile Networks. More in Section 5. 


NEMO Aggregated Home Network: In this arrangement, the Home Network 
actually overlaps with the Mobile Networks. When at home, a 
Mobile Router acts as a bridge between the Home Link and the 
Mobile Networks. More in Section 6. 


Virtual Home Network: In this arrangement, there is no physical Home 
Link at all for the Mobile Routers to come back home to. More in 
Section 7. 


NEMO Mobile Home Network: In this arrangement, there is a bitwise 
hierarchy of Home Networks. A global Home Network is advertised 
to the infrastructure by a head Home Agent (HA) and further 
subnetted into Mobile Networks. Each subnet is owned by a Mobile 
Router that registers it in a NEMO fashion while acting as a Home 
Agent for that network. More in Section 8. 


In all cases, the Home Agents collectively advertise only the 
aggregation of the Mobile Networks. The subnetting is kept within 
the Home Agents and the Mobile Routers, as opposed to advertised by 
means of routing protocols to other parties. 


The examples provided here aim at illustrating the NEMO Basic Support 
[5] but do not aim at limiting its scope of application; additional 
cases may be added in the future. 
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Terminology and Concepts 


The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 
interpreted as described in RFC 2119 [2]. 


Most of the mobility-related terms used in this document are defined 
in the Mobility Related Terminology document [3] and in the Mobile 
IPv6 (MIP6) specification [4]. 

In addition, some terms were created or extended for NEMO. These 
specific terms are defined in the Mobile Network Terminology document 
on 

Home Link 

Home Network 


Home Address 


MRHA Tunnel 


Mobile Aggregated Prefix 

Aggregated Home Network 

Extended Home Network 

Virtual Home Network 

Mobile Home Network 
General Expectations 
With Mobile IPv6, the Home Network is generally a physical network 
interconnecting the Home Agents and the Mobile Nodes that are at 
home. NEMO extends the concept of home so that it is not only a flat 
subnet composed of Home Addresses but an aggregation that is itself 
subnetted in Mobile and Home Networks. This aggregation is still 
referred to as home. 
As an example, consider the case where the aggregation has a global 


routing prefix of m = 48 bits (A:B:C::/48), with a subnet ID size of 
n = 16 bits (n + m = 64): 
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When a Mobile Router, MR1, uses the Mobile Network Prefix (MNP) A:B: 
C:1::/64 with the NEMO Basic Support, MR1 may register using a Home 
Address from the Home network (i.e., A:B:C:0::1) or a Home Address 

from one of its MNPs (i.e., A:B:C:1::1) depending on the deployment. 


In a given deployment, one subnet may be reserved for the Home Link 
(A:B:C:0::/64) while the others are attributed to Mobile Routers as 
Mobile Networks (as A:B:C:1::/64 for MR1). Another approach could be 
to configure the aggregation of Mobile Networks as the subnet on the 
Home Link, and let the Mobile Routers manage the overlapping 
networks. Finally, the aggregation could be configured on a virtual 
network, with no physical Home Link at all, in which case home means 
topologically and administratively close to the Home Agent that 
advertises the virtual network. 


The following sections provide additional information on these forms 
of Home Network. 


MIP Home Network 


In the Mobile IPv6 (MIP6) specification [4], Mobile Nodes are at home 
when they are connected to their Home Link, where they recognize 
their Home Prefix in Router Advertisement messages. Also, a binding 
is checked using Duplicate Address Detection (DAD) on the Home Link, 
and Home Agents discover each other by means of Neighbor Discovery 
(ND) extensions over that link. 


The Home Prefix that is advertized on the Home Link is a final 
prefix, as opposed to an aggregation, and it may be used by hosts on 
the Home Link for autoconfiguration purposes. 


As we see, the concept of a Home Network for Mobile IPv6 is really a 
prefix on a link, served by one or more Home Agents as opposed to a 
routed mesh. We will see in the next sections that NEMO needs 
additional prefixes for use by the Mobile Networks. For that reason, 
NEMO extends the concept of Home Network into a more complex, 
aggregated structure. 


NEMO Extended Home Network 
1. Configuration 


One simple way of extending the MIP Home Network is to use additional 
prefixes, contiguous to the Home Link Prefix inherited from MIPv6, as 
Mobile Network Prefixes. As this model trivially extends the MIP 
Home Network, the resulting aggregation is called a NEMO Extended 
Home Network. It is depicted in Figure 1. 


Thubert, et al. Informational [Page 5] 


RFC 4887 Home Network Models with NEMO Basic July 2007 


route v /48 A:B:C::/48 
HA 
| /64 Home Link: A:B:C:0::/64 
--+-----+--+- . -+- . -+—- 
| | | | 
MR1 MR2 MRi MRN 
| | | | 
/64 /64 /64 /64 MNP A:B:C:i::/64 


Home Net Mobile Net Mobile Net eae Mobile Net 


Figure 1: Extended Home Network 
In that arrangement: 
o There is one physical Home Network and multiple Mobile Networks 


o The Home Prefix and the MNPs are tailored to allow for IPv6 
Stateless Address Autoconfiguration with typical interface 
identifier length for the type of interface (for example, can be 
/64). 


o The prefix length of the Extended Home Network is shorter than 
that of the Home Network and the MNPs, since it is an aggregation 
(for example, can be /48). 


o Since the Extended Home Network operations inherit trivially from 
MIPv6, it can be seen as natural that the Mobile Routers be 
assigned their Home Addresses from the prefix on the Home Link. 
In that case, a Home Agent can perform DAD on the Home Link as 
prescribed by Mobile IPv6 for the Mobile Router Home Addresses 
(MRHAS) . 


5.2. Returning Home 


In the Extended Home Network model, the Home Network is configured on 
a physical interface of the Home Agent, the Home Link. 


A Mobile Router returns home by connecting directly to the Home Link, 
and dropping the MRHA tunnel. 
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When at home, the Mobile Router ensures the connectivity of the 
Mobile Network using standard router operations. 


In implicit mode, the Home Agent has the necessary information to 
continue routing to the MNPs in the absence of registration, assuming 
that the Mobile Router is at home, and the participation of the 
Mobile Router to the home Interior Gateway Protocol (IGP) is not 
required. 


But in explicit mode, or if the Mobile Router uses an IGP over the 
MRHA tunnel, then it needs to resume its IGP operations on the Home 
Link in order to advertise its Mobile Networks to the HA, unless some 
other means such as static routes are deployed to cover the case. 


Alternative procedures for ensuring the connectivity of the Mobile 
Networks when at home are described in Section 7. 


5.3. Home Address from MNP 


We saw that a natural extension of the MIP procedure is to derive the 
Home Address of a Mobile Router from the prefix on the Home Link. 
Alternatively, NEMO basic support allows that a Mobile Router forms 
its Home Address from one of its Mobile Network Prefixes. 


In that case, the Home Address does not match the Home Link Prefix, 
and there is a need to configure the Home Agent in a specific mode 

with the support for the Extended Home Network and the range of the 
Mobile Network Prefixes. Based on that new configuration, the Home 
Agent can accept a Home Address that is not from the Home Link, and 
it will know that it should not perform any DAD. 


Also, if the Mobile Router uses a Home Address that is derived from 
its MNP, some specific support is required on the Mobile Router as 
well. In order to determine that it is at home, the Mobile Router 
recognizes the well-known prefix of its Home Agent as opposed to 
matching the prefix on the Home Link with that of its Home Address. 


When connecting to the Home Link, the Mobile Router also need to 
autoconfigure an address on the Egress interface as opposed to 
assigning its home Address to the interface. 


For all these reasons, this submode of Extended Home Network is not a 


trivial extension of the MIPv6é Home Model, and it might not be 
compatible with all implementations. 
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-4. Deployment Caveats 


-4.1. Mobile Router Side 


In explicit mode, the routing to the MNP via the Mobile Router must 
be restored when the Mobile Router is at home. This is normally 
performed by the Mobile Router by means of the existing IGP. In that 
case, a specific support is required on the Mobile Router to control 
the routing protocol operation, enabling the participation in the IGP 
if and only if the Mobile Router is at home. 


The NEMO Basic Support does not mandate a specific routing protocol 
though the support for some well-known routing protocols can be 
expected from many implementations. An implementation might provide 
an automatic toggle to start/stop routing on an egress interface when 
the mobile router comes back/leaves home. When such a toggle is 
unavailable, then a specific interface should be reserved to attach 
to home with the appropriate settings for security and routing. 


5. Applicability 


The Extended Home Network keeps the MIP6 concept of a Home Network 
for both Mobile Nodes and Mobile Routers to take their Home Address 
from. Since there is no overlap between the prefixes that are 
assigned to MNPs and prefix(es) that are dedicated to the Home Link, 
it is possible for MNs and Mobile Routers to coexist with that model. 


Also, when the Home Address is derived from the prefix on the Home 
Link, the Home Agent behavior on the link trivially extends that of 
MIP and the support for that configuration should be available with 
all implementations. 


There are a number of issues with returning home when a Mobile Router 
configures its Home Address from the MNP as described in Section 5.3. 
Therefore, we do not recommend this mechanism if the Mobile Routers 
attach to the Home Network. 


NEMO Aggregated Home Network 
1. Configuration 


One other approach is to consider that the aggregation of all the 
MNPs is used plainly as the Home Link Prefix. In this model, the 
Home Network is referred to as a NEMO Aggregated Home Network. This 
means that the Mobile Aggregated Prefix is configured on the Home 
Link and advertised by the Home Agent as a subnet, as depicted in 
Figure 2. 
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HA 
| /56 Aggreg /56 
he as tee Cl Ste eee 
MR1 MR2 MRi MRN 
/64 /64 /64 /64 Aggreg|i /64 0< i <=N 
Aggregated Home Network == Home Network 
<-------------------- ---- 5 > 
Mobile Net Mobile Net Mobile Net Sas Mobile Net 
<------------ ><------------ ><------------ > <------------ > 


Figure 2: Aggregated Home Network 


In that model, it seems natural to subnet the whole range of 
addresses into Mobile Network prefixes, as opposed to reserving one 
prefix for the Home Link, which would boil down to the Extended Home 
Network model. If the prefix on the Home Link is really an 
aggregation and not a final prefix, it should not be allowed for 
autoconfiguration or Home Address allocation. 


Note that in that case, it makes sense for a Mobile Router to 
register using a Home Address from one of its own MNPs. Taking the 
Home Address from its own range guarantees the uniqueness of the 
suffix. That uniqueness can be checked by the Mobile Router on its 
Ingress network (see [3]) using DAD. 


6.2. Returning Home 


The Aggregated Home Prefix is configured on a physical interface of 
the Home Agent, the Home Link. As a consequence, the Home Agent has 
a connected route to the Aggregated Home Network over the Home Link. 


A Mobile Router returns home by connecting directly to the Home Link, 
and dropping the MRHA tunnel. The Mobile Router recognizes its Home 
Link by a prefix match with its Home Agent. 


When the Mobile Router forms its Home Address out of one of its MNPs, 
since the Home Network prefix is an aggregation that encompasses all 
the MNPs, the Home Address actually matches both prefixes. To 
properly identify the Home Network as it returns home, the MR must 
expect a shorter prefix length than that of the MNP from which the 
Home Address was formed. 
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6.2.1. Returning Home with the Egress Interface 


A Mobile Router coming home via its Egress interface sees overlapping 
prefixes between the Ingress and the Egress interfaces and some 
specific support may be needed: 


When a Mobile Router connects to the Home Link using its Egress 
Interface, it might set up a bridge between its Ingress interface(s) 
and the Home Link, if the interfaces are compatible. 

Alternatively, the Mobile Router might perform ND proxying for all 
addresses in its MNPs, between the Egress interface and the related 
Ingress interface, as described in [8]. Since the prefixes on the 
Egress and Ingress interfaces are overlapping, routing is disallowed. 
The Mobile Router does not need to join the local IGP when returning 
home, even if it is using the explicit Prefix Mode. When the Mobile 


Router is not registered, the Home Agent simply expects that all 
Mobile Network Nodes (MNNs) will be reachable over the Home Link. 


Figure 3: Bridging between Egress and Ingress 
6.2.2. Returning Home with the Ingress Interface 
Alternatively, if the Mobile Router has a single Ingress interface, 


the Mobile Router may use the NEMO-Link to connect to the Home Link, 
merging the two links in a single consistent network. 


Figure 4: Merging the Home and the Mobile Networks 
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This fits the connected route model, since the Aggregated Home 
Network is truly located on that network. Note that in that case, it 
makes sense for a Mobile Router to register using a Home Address from 
one of its own MNPs. 


6.3. Applicability 


With this model, there is no specific space for independent nodes, as 
any address in the aggregation belongs to a MNP, and thus to a Mobile 
Router. This configuration excludes the cohabitation with MIP6 MNs 
on the Home Link. 


6.4. Deployment Caveats 
6.4.1. Home Agent Side 


A node on the Home Link receiving a Router Advertisement that 
includes the Aggregated Home Network prefix might use that prefix for 
Address Autoconfiguration. Such a node would also install a 
connected route to the Aggregated Home Network over the Home Link. 


As a result, unless the node has a better (longest match) route toa 
given Mobile Network Prefix, it would look up all MNNs on that MNP 
using Neighbor Discovery over its interface to the Home Link, and 
fail. 


Thus, on the Home Link, the Home Agent must intercept all the packets 
for ALL the Mobile Network Nodes on the registered prefixes; that is, 
for ALL nodes attached to Mobile Routers that are away from home. 
This should be a layer 2 operation, rather than layer 3. The Home 
Agent might, for example, perform some form of ND proxying for all 
addresses in all registered Mobile Network Prefixes. 


The Home Agent must also protect the MNP space from autoconfiguration 
by uncontrolled visitors at Neighbor Discovery level. 


There is a need to provide a specific configuration on the Home Agent 
to specify that it operates in Aggregated Mode. If a Home Agent 
implementation is simply derived from that of MIP, then the 
capability to perform the required proxying might not exist, and the 
Aggregated Mode will not operate properly for nodes on the Home Link. 


6.4.2. Mobile Router Side 


If the Mobile Router returns home by Egress, a specific support is 
required to control the bridging operation depending on whether or 
not a Mobile Router is at home. This support might not be present in 
all implementations. 
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The NEMO Basic Support does not mention a specific behavior for 
bridging though bridging capabilities can be expected from many 
implementations. An implementation might provide an automatic toggle 
to start/stop bridging on an Egress interface when the Mobile Router 
comes back/leaves home. When such a toggle is unavailable, then a 
specific interface should be reserved to attach to home with the 
appropriate settings for security and bridging. 


Also, note that NEMO authorizes multiple registrations for a same MNP 
by different Mobile Routers. This is a case of multihoming, and it 
normally means that the Mobile Routers are interconnected by the 
Ingress network that bears the common MNP. But there is no provision 
in NEMO Basic Support to test that this condition is met at binding 
time and maintained over time. 


It is thus possible for 2 different Mobile Routers to register the 
same prefix with different Home Addresses, and this will cause an 
undetected problem if the corresponding Ingress interfaces are not 
connected. 


When the Home Address of a Mobile Router is derived from its MNP, 
there is thus an additional risk of an undetected misconfiguration if 
the Home Address is autoconfigured from the Ingress interface as 
opposed to statically assigning an address and MNP. 


A Mobile Router that is at home must own an address from the 
aggregation on its Egress interface and an address from its MNP -- a 
subnet of that aggregation -- on its Ingress interface. A pure 
router will reject that configuration, and the Mobile Router needs to 
act as a bridge to use it. In order to deploy the Aggregated Home 
Network model, one must check whether that support is available in 
the Mobile Routers if returning home is required. 


NEMO Virtual Home Network 
1. Configuration 

The Home Link can be configured on the Home Agent on a virtual link, 
in which case there is no physical Home Link for Mobile Routers to 


return home to, or for Home Agents to discover each other and perform 
the ND-level interactions on, as described in Mobile IPv6 [4]. 
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/48 e.g.: A:B:C::/48 
HA 
| /64 A:B:C::/64 
--+-----+--+- . -+- . -+—- 
| | | | 
MR1 MR2 MRi MRN 
/64 /64 /64 /64 A:B:C:i::/64 0 < i <=N 


Figure 5: Virtual Home Network 


The Extended Home Network and the Aggregated Home Network models can 
be adapted for virtual links. 


As in the case of a physical link, the Home Address of a Mobile 
Router can be constructed based on a dedicated subnet of the Home 
Prefix or one of the Mobile Router MNPs. 


Note that since the Home Address is never checked for DAD, it makes 
the configuration easier to take it from the MNP as opposed to a 
specific subnet. 


There are certain advantages to making the Home Link a virtual link: 


A virtual link may not experience any disruption related to 
physical maintenance or to hardware problems, so it is more 
available than a physical link. The high availability of the Home 
Link is critical for the mobility service. 


The Home Agent does not have to defend the Mobile Router’s Home 
Address through Proxy Neighbor Discovery. The Home Agent does not 
also have to perform Duplicate Address Detection (DAD) for the 
Mobile Router’s Home Address when it receives a Binding Update 
from the Mobile Router. 


The Mobile Router does not have to implement the Returning Home 
procedure (Section 11.5.4 of Mobile IPv6 [4]). 


There are also some drawbacks to the Virtual Home Link approach: 


RFC 3775 [4] and RFC 3963 [5] do not provide the specific support 
for a Mobile Node to emulate returning home on a Virtual Home 
Network. In particular, in the case of NEMO, the routing 
information from the Mobile Router being injected on the IGP might 
adversely affect IPv6 route aggregation on the Home Network. 


There can be only one Home Agent since Mobile IPv6 relies on 


Neighbor Discovery on the Home Link for other Home Agent discovery 
and for Duplicate Address Detection. 
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The Home Agent must maintain a Binding Cache entry for a Mobile 
Router and forwarding state for its Mobile Network even when the 
Mobile Router is directly connected to it. All traffic to and 
from the Mobile Network is sent through the bi-directional tunnel 
regardless of the Mobile Router location. This results in a 
tunneling overhead even though the Mobile Router is connected to 
the Home Network. 


Suggestions on how to perform an equivalent of returning home on a 
Virtual Home Network have been proposed, but this topic is outside of 
the scope of this document. 


.2. Applicability 


NEMO operations rely on ND extensions over the Home Link for the Home 
Agent to Home Agent communication. 


Making the Home Link virtual bars the deployment of multiple Home 
Agents, which may be desirable for reasons of load balancing. Please 
refer to the NEMO multihoming issues [9] for more on this. 


Yet, for a deployment where a single Home Agent is enough, making the 
Home Link virtual reduces the vulnerability to some attacks and to 
some hardware failures, while making the Home Agent operation faster. 


Note that NEMO basic does not mandate the support of Virtual Home 
Networks. 


NEMO Mobile Home Network 
1. Configuration 


In this arrangement, there is a bitwise hierarchy of Home Networks. 
A global Home Network is advertised to the infrastructure by a head 
Home Agent (s) and further subnetted into Mobile Networks. As a 
result, only the Home Agent (s) responsible for the most global 
(shortest prefix) aggregation receive all the packets for all the 
MNPs, which are leaves in the hierarchy tree. 


Each subnet is owned by a Mobile Router that registers it in a NEMO 
fashion while acting as a Home Agent for that network. This Mobile 
Router is at home at the upper level of hierarchy. This 
configuration is referred to as Mobile Home. 


An example of this is the Cab Co configuration. Cab Co is a taxi 
company that uses a /32 prefix for its Home Network, this prefix 
being advertised by the company headquarters (HQ). Regional offices 
are deployed around the country. Even though these regional offices 
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are relatively stable in terms of location and prefix requirement -- 
say, this changes every few years -- making them mobile allows a 
simpler management when a move has to take place, or should the ISP 
service change. 


To illustrate this configuration, we make up the prefixes to reflect 
their role, like CAB:C0::/32 for the Home Network: 


global Home Network CAB:C0::/32 advertised by HQ 


CAB:C0O:CA5A:CA5A::CA5A 
CAB:C0O:CA5A:CA5A::CA5B 
are HAs on link with for each office a route like 


<------------------------ ---- - - - > 
HQ Extended Home Net Mobile Home for SFO office 
(casa) 
CAB:C0:CA5A::/48 CAB:C0:5F0::/48 
<---------------------------- > l... <2 - > 
Home for offices HQ | 
CAB:C0O:CA5A:CASA::/64 MN | 
<---------------------- ><----> | 


CAB:C0:CA5A:CA5A::5F0 <------------ via 
is the Home addr 
of SFO office 
Figure 6: CAB Company HQ Configuration 


Finally, each regional office owns a number of taxis, each one 
equipped with a mobile router and an associated /64 prefix. 


For each Office, say San Francisco (SFO) as an example: 
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Mobile Home Network CAB:C0:5F0::/48 owned by SFO office 


<------------------------ ---- - - - - > 
SFO Home Network Mobile Networks for taxis 
for taxis gern aes estos enans aa a > 
CAB:C0O:5F0:5F0::/64 CAB:C0:5F0:CAB1::/64 CAB:CO:5F0:....::/64 
<------------------- ><------------------- > <------------------- > 
CAB:C0:5F0:5F0::5F0 | 


is HA on link with for 
each taxi a route like 


CAB:C0:5F0:5F0::CAB1 <------ via 


is the Home Address 
of CAB 1 
Figure 7: CAB Company regional configuration 


Note that this is a hierarchy in terms of MR-HA relationship, which 
may not be reflected in the physical arrangement of nodes at a given 
point of time. For instance, in the Cab Co case, some SFO cabs might 
attach to any hot spot or Cab Co office in a different city, and the 
SFO office might be at home if it is co-located with the 
headquarters. But note that SFO should never attach to one of its 
own cabs. This would create a stalemate situation, as documented in 
the NEMO Route Optimization (RO) problem statement [7]. 


But it is also possible to reflect the organizational hierarchy in a 
moving cloud of Mobile Routers. If a Mobile Home Agent acts as 
root-MR for a nested configuration of its own Mobile Routers, then 
the communication between Mobile Routers is confined within the 
nested structure. 


This can be illustrated in the case of a fleet at sea. Assume that 
SFO is a communication ship of a fleet, using a satellite link to 
join the infrastructure, and that the cabs are Mobile Routers 
installed on smaller ships, equipped with low-range radios. 


If SFO is also the root-MR of a nested structure of its own cabs, the 
communication between cabs is relayed by SFO and does not require the 
satellite link. As for traffic to the outside of the nested NEMO, 
SFO recursively terminates the nested tunnels from its cabs and 
reencapsulates all the packets between the nested cloud and 
correspondents in the infrastructure in a single tunnel to CA5A. As 
a result, the unwanted effect of nesting of tunnels is avoided over 
the Internet part of the packet path. 
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8.2. Applicability 


This complex topology applies to a large distributed fleet, mostly if 
there is a single interchange point with the Internet (e.g., a 
Network Address Transition (NAT) or a SOCKS [1] server farm) where 
the super Home Agent could be located. 


One specific benefit is that when 2 Mobile Routers travel together 
with a common Home Agent, the traffic between the 2 is not 
necessarily routed via the infrastructure, but can stay confined 
within the mobile cloud, the Mobile Home Agent acting as a rendezvous 
point between the Mobile Routers. This applies particularly well for 
a fleet at sea when the long-haul access may be as expensive as a 
satellite link. 


9. Security Considerations 
This document only explains how a Home Network can be deployed to 
support Mobile Routers and does not introduce any additional security 
concerns. Please see RFC 3963 [5] for security considerations for 
the NEMO Basic Support protocol. 
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